Skip to content

COMP: Report a VTK/ITK Python mismatch clearly in ITKVtkGlue - #6983

Merged
hjmjohnson merged 1 commit into
InsightSoftwareConsortium:mainfrom
dzenanz:dev
Oct 23, 2026
Merged

COMP: Report a VTK/ITK Python mismatch clearly in ITKVtkGlue#6983
hjmjohnson merged 1 commit into
InsightSoftwareConsortium:mainfrom
dzenanz:dev

Conversation

@dzenanz

@dzenanz dzenanz commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

When ITK's selected Python differs from the one a Python-wrapped VTK was built with, ITKVtkGlue now fails with an error naming both, instead of FindPython3's misleading "missing: Development.Module".

Root cause

On Windows, FindPython3 searches the registry before PATH and takes the newest version in range, so ITK's interpreter lookup can select e.g. Python 3.14. VTK's vtk-find-package-helpers.cmake then fills Python3_INCLUDE_DIR/Python3_LIBRARY with its build-time (3.12) paths but keeps the already-set 3.14 interpreter. The mixed artifacts make VTK's own find_package(Python3 ... Development.Module) fail.

find_package(VTK) is no longer REQUIRED, so the failure surfaces as VTK_Python_FOUND=0 and ITK reports the interpreter and VTK's include/library paths, pointing at Python3_EXECUTABLE. A missing VTK gets its own error.

Test results

Windows 11, VS 2026, CMake 4.4.4, configure only (ITK_BUILD_DEFAULT_MODULES=OFF, Module_ITKVtkGlue=ON, BUILD_SHARED_LIBS=ON, BUILD_TESTING=ON), VTK 9.7 wrapped with Python 3.12, Python 3.14 also installed:

Python3_EXECUTABLE main this PR
unset (ITK selects 3.14) FindPython3 "missing: Development.Module" new clear FATAL_ERROR
Python 3.12 configures configures
AI assistance
  • Tool: Claude Code
  • Role: diagnosed a nightly dashboard configure failure, implemented the change, ran the configure matrix above
  • All changes reviewed by the submitter

PR Checklist

  • No API changes were made (or the changes have been approved)
  • No major design changes were made (or the changes have been approved)
  • Added test (or behavior not changed)
  • Updated API documentation (or API not changed)
  • Added license to new files (if any)
  • Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
  • Added ITK examples for all new major features (if any)

🤖 Generated with Claude Code

@github-actions github-actions Bot added type:Compiler Compiler support or related warnings type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots area:Bridge Issues affecting the Bridge module labels Oct 22, 2026
@dzenanz
dzenanz marked this pull request as ready for review October 22, 2026 20:16
@greptile-apps

greptile-apps Bot commented Oct 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable defects were established.

Summary

Finds VTK before ITK chooses Python when Module_ITKVtkGlue is explicitly enabled.

  • ITK uses the Python that its wrapped VTK was built with.

dzenanz explicitly noted that indirect module enablement does not find VTK early.

Diagram

 
%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[ITK needs Python] --> B{Module_ITKVtkGlue enabled explicitly?}
  B -->|Yes| C[Find VTK first]
  C --> D{VTK and its Python usable?}
  D -->|No| E[Stop with an error]
  D -->|Yes| F[Run ITK Python discovery]
  B -->|No| F
  F --> G[Resolve and build enabled modules]
Loading

Reviews (1) · Last reviewed commit: "COMP: Make ITK use the Python that a Pyt..." · Reviewed by Greptile

@dzenanz

dzenanz commented Oct 23, 2026

Copy link
Copy Markdown
Member Author

Can we review/merge this today? I hit this problem again on my Mac.

@blowekamp
blowekamp self-requested a review October 23, 2026 13:52
blowekamp
blowekamp reviewed Oct 23, 2026
View reviewed changes

@blowekamp blowekamp left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in VtkGlue look good.

I have concern that directory calling VtkGlue's its-module-init.cmake out of order may have side-effects. Additionally it's not a sustainable practice for other modules that have pre-requisites.

If you set the configuration of ITK to the matching VTK's python executable does the configuration work with out the addition of the line to the top-level cmake?

@dzenanz
COMP: Report a VTK/ITK Python mismatch clearly in ITKVtkGlue
9f92d17 
A Python-wrapped VTK's config fills Python3_INCLUDE_DIR and
Python3_LIBRARY from its build but keeps an already selected
Python3_EXECUTABLE. When the two Pythons differ, FindPython3 failed
inside VTK's config with a misleading missing Development.Module
error. Find VTK without REQUIRED and report the selected interpreter
and VTK's Python paths instead.
@dzenanz dzenanz changed the title COMP: Make ITK use the Python that a Python-wrapped VTK was built with COMP: Report a VTK/ITK Python mismatch clearly in ITKVtkGlue Oct 23, 2026
@github-actions github-actions Bot removed the type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots label Oct 23, 2026
@dzenanz

dzenanz commented Oct 23, 2026

Copy link
Copy Markdown
Member Author

@blowekamp Good call. I dropped the top-level CMakeLists.txt change, so itk-module-init.cmake again runs only during module enablement. Including it early didn't change anything ITK reads, but it did run the file twice (the static-VTK warning would have printed twice) and loaded VTK and its dependency settings earlier than usual.

To your question: yes. With Python3_EXECUTABLE set to VTK's Python, configure works without that line, on both main and this PR. The line only mattered when Python3_EXECUTABLE was unset: ITK would then adopt VTK's Python automatically. Without it, ITK can pick a newer Python, and this PR now turns FindPython3's "missing: Development.Module" into an error naming the selected interpreter and VTK's Python include and library paths, telling the user to set Python3_EXECUTABLE.

@hjmjohnson
hjmjohnson merged commit 46e4582 into InsightSoftwareConsortium:main Oct 23, 2026
19 checks passed
@dzenanz
dzenanz deleted the dev branch October 23, 2026 19:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@hjmjohnson hjmjohnson hjmjohnson approved these changes
@blowekamp blowekamp blowekamp approved these changes

Assignees

No one assigned

Labels

area:Bridge Issues affecting the Bridge module type:Compiler Compiler support or related warnings

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@dzenanz @hjmjohnson @blowekamp